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Abstract 

Multivariable control allows controller designs that can provide decoupled command tracking and 
robust performance in the presence of modeling uncertainties. Although the last two decades have 
seen extensive development of multivariable control theory and example applications to complex 
systems in software/hardware simulations, there are no “production” flying systems - aircraft or 
spacecraft, that use multivariable control. This is because of the tremendous challenges associated 
with implementation of such multivariable control designs. Unfortunately, the curriculum in schools 
does not provide sufficient time to be able to provide an exposure to the students in such 
implementation challenges. The objective of this paper is to share the lessons learned by a 
practitioner of multivariable control in the process of applying some of the modem control theory to 
the Integrated Flight Propulsion Control (IFPC) design for an advanced Short Take-Off Vertical 
Landing (STOVL) aircraft simulation. 
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Overview 



• Control design problem and typical 
mathematical formulation 

• Unique nature of multivariable control (MVC) 

• Benefits and Capabilities of MVC 

• Challenges and barriers to using MVC in real 
systems (with reference to STOVL IFPC Design) 

- Right problem formulation 

- Major implementation issues 


- Making changes on-the-fly 

• Conclusion 



Overview 

The paper, which is based on a lecture on the topic as part of the NASA NESC (NASA Engineering 
and Safety Center) course on Satellite Attitude Control Systems, covers the following topics: i) 
Unique nature of “Multivariable Control (MVC)”; ii) Benefits and Capabilities of Multivariable 
Control; iii) Challenges and barriers of using multivariable control designs in real flight systems. The 
paper starts by describing what is meant by Multivariable Control and provides a brief comparison of 
“Classical” versus “Modem” methods of control law design. The motivation for using Multivariable 
Control is then discussed in terms of robustness and performance benefits of various synthesis 
approaches (e.g., LQG/LTR (Linear Quadratic Gaussian/Loop Transfer Recovery), El-infinity etc.). 

A practitioner’s perspective is provided on when to use Multivariable Control - and more 
importantly when not to! Some of the challenges associated with formulating the problem right 
within the limitations and flexibilities of the multivariable control synthesis techniques are then 
discussed with a focus on 3 areas: Control effector blending, addressing nonlinearities, and controller 
stability. Insight is provided into two major issues with implementing multivariable control: Gain 
Scheduling, and Integrator Wind up Protection. Finally, the issue of having to make amendments 
based on problems encountered during testing and/or operation is discussed. 

The above challenges and barriers are discussed with reference to the author’s experience with the 
STOVL IFPC design and its evaluation on a fixed-base piloted simulation. Tools and techniques for 
overcoming some of the barriers are also presented with illustrative examples from the STOVL IFPC 
design study. The hope is that this paper will provide a basis for students of multivariable control 
theory to get a broad perspective of issues that need to be addressed when it comes to implementing 
the theory based designs to complex systems. 
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Control Design Problem 



• Given model of “plant,” find control law which provides: 

- Desired command tracking in presence of disturbances 

- Robustness to modeling uncertainties 

- Stable operation when encountering limits 

• Keep integrated system perspective when developing control^ 

Glenn Research Center 



Control Design Problem 

Simply stated, the control design problem is: Given a model of the “plant”, find control law which 
provides desired command tracking in the presence of disturbances, robustness to modeling 
uncertainties and stable operation when encountering limits. Although the focus of this paper is on 
the control laws which are embedded in the controller hardware, it is important to keep an overall 
systems perspective in mind when designing the control laws since a control system consists of many 
separate components, such as the actual control hardware and software, an actuation system, a 
sensing system, on-board models etc. 

It is important to note that the real plant always has some disturbances e.g., gust for flight control. 
These disturbances need to be adequately represented in the formulation of the control design 
problem. Also, do not forget, that when you do the control law design, you’re working with a 
mathematical model of the plant. Modeling has many issues; there are uncertainties associated with 
the modeling approach as well as the parameters used to represent physical phenomenon, 
approximations are made to keep the mathematical model tractable, etc. It is important to be 
knowledgeable about the assumptions made in developing the mathematical model of the plant and 
what impact these assumptions might have in terms of controlling the model vs. controlling the plant. 
The importance of robustness to modeling uncertainties is very well understood and there has been 
extensive literature on robust control design methods. 

However, the third requirement, to have stable operation when encountering limits, is typically not 
covered in control courses. Every system has hardware limits, such as actuator positions and rates, as 
well as operational limits imposed for safety. It is important to have a good understanding of the 
typical limits for a system and to build in limit protection such that the control laws will provide 
graceful performance degradation and will not drive the system unstable when limits are 
encountered. 
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MVC Unique Nature 


• Systems with >1 output being controlled by >1 manipulated input, 
with any given input affecting more than single output: multi- 
input/multi-output (MIMO) 

• “Classical” methods: based primarily on frequency domain 
approach, extend single-input/single-output (SISO) transfer function 
techniques, e.g., Nyquist, to MIMO transfer function matrix 

• “Modern” methods: based on state-space approach, formulation of 
quadratic cost function resulting in linear control law typically solved 
through system of Ricatti equations 

- Control solution easily amenable for digital implementation 

- Analysis typically done using multivariable frequency domain 
techniques 

• Unlike simple gain and phase margin measures for SISO, 
“robustness” determination of MVC control requires complex 
analyses using singular value techniques and Monte Carlo 
simulations 


Glenn Research Center 
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MVC Unique Nature 

A multivariable control or a multi-input/multi-output (MIMO) system is a system with more than one 
output being controlled by more than one manipulated input. And the important part is that any given 
input affects more than a single output. If each input only affects a single output, then you basically 
have a combination of single-input/single-output systems, and you don’t need multivariable control 
for that. There are many approaches to MVC - some approaches such as Multivariable Nyquist 
Theory extend the classical single-input/single-output approaches to multivariable control, modem 
state-space based methods which center around an optimal solution of a quadratic cost function, 
optimization methods such as neural networks etc. The discussion in the rest of the paper is pertinent 
to any multivariable control design regardless of the synthesis approach, however, the discussion will 
be based on controllers synthesized using modern state-space based methods. There are emerging 
nonlinear control design approaches such as MPC (Model Predictive Control) which might not have 
some of the same issues as those being discussed in this paper. However, such approaches are still at 
a development stage with respect to aerospace applications. 

As an aside, it is important to note that the quadratic formulation of the cost function is used in 
typical state-space methods, such as LQR (Linear Quadratic Regulator) because it results in an 
optimal control law which is linear - typically obtained through solving a system of Ricatti 
equations. The control solution is easily amenable to digital implementation, as well as allows all the 
linear analysis tools to be used for performance and robustness analysis of the closed-loop system. 

Analysis of control laws is still done using frequency domain techniques. So, to be a good control 
design engineer, it is very important to get the basics right with respect to frequency domain 
analyses. If you don’t understand gain margin, phase margin, Bode plots etc. and their implications 
for closed loop system performance and robustness, it’s very, very difficult to apply the multivariable 
frequency domain analyses techniques, such as singular value analysis and “mu-analysis” techniques 
in a meaningful way. 
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• “1-step” control solution for complex intercoupled systems 

- Decoupled command tracking 

- “Optimal” control usage 

• When to use MVC: 

- System has high level of input/output coupling and not 
much separation in loop bandwidths 

- Physics of problem are reasonably well-understood to be 
able to use “design handles” effectively 

- System is complex with large number of states 

- When sequential SISO loop closure will not meet 
performance requirements! 

• Remember: MVC cannot make 747 fly like F-16 ! 

Glenn Research Center 


Why use multivariable control? Because if you have a truly MIMO (multi-input/multi-output) 
system, doing sequential loop closures or trying to do decoupled command tracking becomes very, 
very difficult. Multivariable control provides “one-step” solution for complex intercoupled systems 
with systematic approaches to perform the fundamental trade-offs between performance, control 
usage and robustness. Although the typical quadratic cost function formulation implies that the 
control law is “optimal” in some way, as will be discussed later, it is important to be aware that the 
“optimality” is based on the way the design plant is formulated, including the choice of the weights 
in the quadratic function, for control law synthesis and it might lead to unexpected results in terms of 
control usage when implemented on the system. 

Also it is important to emphasize that MVC cannot be meaningfully applied unless the control 
designer has a good basic understanding of the physics of the system being controlled or works in 
close coordination with someone who has such expert knowledge. The idea of “give me a math 
model and give me requirements, and I will come up with a control law that meets the requirements” 
is fine for a classroom project, but does not work too well in real life. Understanding the physics of 
the problem allows the control designer to better apply the “design handles” in the selected control 
synthesis approach and to ensure that the limitations of the math model will not result in a control 
law that does not meet the design requirements when integrated with the physical system. 

No matter how fancy your multivariable control synthesis approach is, or how good a control 
designer you are, you cannot make a 747 actually fly like an F-16, because of the inherent dynamics 
of the system and the limitations on the available control authority! The physical properties such as 
mass, inertia, aerodynamics, control surface sizes etc. determine the limitations on achievable 
performance, regardless of what control synthesis technique is used. 



MVC Benefits and Capabilities 
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Typical MVC Approaches 


• Loop shaping techniques such as LQG/LTR, H-infinity, Mu-synthesis 

- Trade-off between performance, robustness and control usage 

- Control objectives are indirectly reflected in formulation — requiring 
iteration to ensure objectives are met 


• Critical to formulate problem such 
that it reflects design goals 

- Control rate weighting to 
reflect rate limits 

- Scaling to accommodate 
large variations in dimensions 



•Typical state-based approaches have controller order > “plant” order; 
controller order reduction becomes necessary 
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Typical MVC Approaches 

Modem multivariable control approaches such as H-infinity, mu-synthesis, LQG/LTR (Linear 
Quadratic Gaussian/Loop Transfer Recovery) take the best of state-space and frequency domain 
techniques and merge them for robust control synthesis. All these are based on providing “handles” 
to make intelligent tradeoffs, through trial and error, between performance, robustness and control 
usage. The fundamental trade-off between performance and robustness for closed-loop systems is 
evident from the relationship between the sensitivity and transmission (complimentary sensitivity) 
functions which is covered in a typical multivariable control course. 

The generic formulation for H-infinity control synthesis is shown in the block diagram. By selecting 
appropriate weightings WS, WT, and WC on the sensitivity, transmission and control functions, 
respectively, the designer can achieve the desired trade-off between performance, robustness and 
control usage. In terms of control usage, it is important to provide a mechanism to limit the control 
rate in the synthesis process. If the control rate is not weighted properly, it is possible that the control 
law will result in large control rates thus hitting the control rate limit and violating all assumptions of 
linearity. When formulating the design plant, it is also important to keep in mind that scaling has a 
significant impact on the resulting control law. All the multivariable analyses tools are based on 
inputs and outputs being of comparable dimensions. For instance, in aircraft engine control, we have 
interest in controlling the rotor speed, measured in 1000s of rpm, and pressure gain across the fan, 
measured in single digit psi. If the design model is not scaled appropriately, the large units for fan 
speed will end up overshadowing the small changes in pressure. 

The order of the controller resulting from modern multivariable control methods is equal to or greater 
than the order of the design plant. From implementation perspective (limited throughput and memory 
in control hardware), it is important to keep the controller order low, so typically controller order 
reduction will be necessary. 
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MVC Design Challenges: 
Right Problem Formulation 


• Synthesis methods based on mathematical formulation 
that allows for “easier” solution — only indirectly address 
control objectives 

• Numerical stability might require some modifications: 

- Scaling (discussed earlier) 

- Replacing pure integrators with “slow poles” 

• Overlooking key physics of problem in process of 
formulating “design plant” can lead to problems 

- Control effector blending 

- Addressing nonlinearities 

- Controller stability 

Glenn Research Center 


The control synthesis methods are based on a mathematical formulation that allows for “easier” 
solution - they only indirectly reflect the control objectives. For instance, as discussed earlier, there 
is no direct way of incorporating control position and rate limits in the synthesis process. Since, 
typically the control law solution consists of solving a set of algebraic Ricatti equations, it might be 
necessary to make some modifications in the “design” plant to make sure that numerical stability 
problems are not encountered. Plant scaling and replacing pure integrators with slow poles are some 
examples of such modifications. 

As was discussed earlier, lack of understanding of the “physics” of the problem can lead to totally 
unacceptable control law designs. Three things to keep in mind, which have a significant impact on 
practical applicability of the control law synthesized through the multivariable control design 
technique are: i) Control effector blending; ii) Addressing nonlinearities within the capability of the 
linear methods; iii) Assessing the stability of the controller itself. These issues and how to properly 
address them will be discussed in the next section. 



MVC Design Challenges: Right Problem Formulation 
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MVC Design Challenges: 
Control Effector Blending 


• Typical quadratic type formulations can result in controls 
“fighting” each other, specially if 2 control effectors have 
very similar influence on plant 

• Use knowledge of problem physics to “blend” or “gang” 
control effectors into pseudo-controls 


- Typically blend physical effectors into effective force 
and moment generators 



MVC Design Challenges: Control Effector Blending 

If the design plant is such that 2 or more control effectors have “similar” effect on the plant, then the 
“optimal” control law might be such that the control effectors end up “fighting” each other in order 
to provide the best performance. It is best to use the knowledge of the physics of the problem to 
blend or gang control effectors into pseudo-controls for the mathematical formulation. For physical 
control effectors, you would typically combine them into effective force and moment generators. 

The schematic shown above is for a conceptual advanced STOVL (Short Take-Off and Vertical 
Landing) aircraft which was used for development of integrated flight/propulsion control methods 
(see Reference below). In the transition from cruise to hover phase, the aircraft is controlled using 
both aerodynamic effectors (elevons and rudder) and propulsive effectors (ejectors on the wings, 
vectorable main and ventral nozzle and 5 RCS (reaction control system) thrusters). Although there 
are 5 RCS thrusters, it is important to note that the Pitch RCS and the 2 Yaw RCS thrusters provide 
thrust only in one direction. So the Pitch RCS is used for pitch up commands while the two Roll RCS 
thrusters are used collectively for pitch down commands. Similarly, the right Yaw RCS is used for 
heading left whereas the left Yaw RCS is used for heading right. If both the Yaw RCS thrusters were 
used in the control design model, then it will result in a control law that uses the two thrusters 
differentially to improve yaw control which will be inconsistent with the implementation, i.e., only 
one or the other should be active. Similarly, if both the Roll RCS thrusters along with the Pitch RCS 
thrusters are used in the control design model, then the control law can result in Roll thrusters 
fighting the Pitch thruster and will also command downward Pitch RCS for pitch down maneuvers 
which is again inconsistent with the actual implementation. How to do the control blending to 
address the limitations of the RCS thrusters will be discussed next. 

Ref: Garg, S., “Robust Integrated Flight/Propulsion Control Design for a STOVL Aircraft Using H- 
infinity Control Design Techniques,” Automatica, vol. 29, no. 1, pp. 129-145, 1993. 
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MVC Design Challenges: Control 
Effector Blending (cont.) 


RCS blending for STOVL 
aircraft 

• Use 3 “effective” RCS 
areas 

• Allows formulating 
“design plant” such that 
it reflects how control 
effectors are actually 
used 



Glenn Research Center 

mum 


MVC Design Challenges: Control Effector Blending (cont.) 

For the purposes of H-inflnity based MVC synthesis for the STOVL aircraft, the 5 RCS thruster 
areas were combined into 3 effective areas - AQR, AYR and ARR for pitch, yaw and roll control, 
respectively. An RCS distribution logic that will distribute the three design model RCS commanded 
areas to the five actual areas in the nonlinear control implementation is shown in the figure above. 
Since the Pitch RCS thruster only provides positive (pitch up) pitching moment, a negative AQR 
command is distributed among the left and right wing tip RCS thrusters to generate the commanded 
negative pitching moment taking into account the relative pitch control effectiveness of the nose and 
wing tip RCS thrusters. The ARR command is distributed differentially among the 2 Roll thrusters, 
and the AYR command is sent to either the left or the right Yaw RCS thruster depending on the 
direction for the heading command. 

This approach allows formulating the design plant such that it reflects how the control effectors are 
actually used. 
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MVC Design Challenges: 
Addressing Nonlinearities 


• Linear control design methods assume that “plant” behaves linearly 
in neighborhood of design point 

- Not always true for some nonlinearities: e.g., Hysteresis, 
Stiction, Absolute value etc. 


• For STOVL example: 

- RCS uses bleed flow that acts as disturbance for engine 

- WB ~ Abs (ARCS) — you can’t pump airflow into engine through 
RCS! 

- Integrating airframe/engine model removes explicit dependence 
on bleed flow with ARCS appearing as direct control effectors 

• Control design using linear integrated controller results in 
ARCS being used to improve engine dynamics by pumping 
flow back! 


• Fix: Design model modified: 

- Elements of “B” matrix from ARCS to engine states are zero 

- Bleed flow added as external disturbance to engine states^ 

Glenn Research Center 



MVC Design Challenges: Addressing Nonlinearities 

The linear design methods assume that the plant behaves linearly in the neighborhood of the design 
point. This is not always true for some nonlinearities such as hysterisis, stiction, absolute value etc. 
Care should be taken in formulating the design plant when there are such nonlinearities in the 
system. 

For the STOVL integrated flight/propulsion control design example, engine compressor bleed flow is 
used for the RCS thrusters. Note that there is an absolute value nonlinearity in the relationship from 
commanded RCS areas compressor bleed flow demand in that although the RCS area may be 
positive or negative, depending on the desired direction of the RCS thrust, the compressor bleed flow 
demand (WB) to generate the thrust is always positive. In an earlier control design problem 
formulation, this nonlinearity was not properly accounted for and the resulting controller was shown 
to lead to unacceptable performance when evaluated with this nonlinearity. The linear control design 
was such that RCS areas were being used to “pump back” air into the engine to regulate the engine 
dynamics in the presence of disturbances due to aircraft motion. 

The physics of the problem says that the bleed flow acts as a disturbance on engine dynamics and 
that the RCS thrusters are to be used for flight control and not for engine control. To reflect this 
physics, the elements of the control input matrix, “B” in the linear design plant, which relate RCS 
areas to engine states were set to 0, i.e., the RCS areas do not affect the engine operating point, and 
bleed flow was added as an external disturbance affecting the engine dynamics in the design plant. 
This formulation resulted in a linear control law design which was able to regulate engine dynamics 
in the presence of bleed flow demands to achieve commanded aircraft maneuvers. See the Reference 
listed on page 8 for further details of this design plant formulation and the closed-loop controller 
evaluation. 
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MVC Design Challenges: 
Controller Stability 

MVC design approaches “guarantee” closed-loop stability — what 
about stability of controller itself? 



K(s) Stable? 


• Implementation issues such as independent V&V, operation across 
multiple modes, etc. require that controller implemented be stable 

• Check resulting design from your favorite synthesis method to make 
sure controller is stable 


• What if it is not? 


- Do analysis to see if design plant is “strongly stabilizable” 

- Try making changes in performance specifications and/or design 
plant formulation 

Glenn Research Center 



MVC Design Challenges: Controller Stability 

MVC synthesis techniques guarantee stability of the closed loop system, but what about the stability 
of the controller itself? None of these techniques guarantee the stability of the controller (K(s) in the 
above figure). The novice control designer might ask: “why do I care about controller stability as 
long as the closed-loop system is stable?”. One has to keep in mind that implementing the controller, 
as software in the control hardware, requires independent Verification and Validation (V&V) of the 
control software. If the controller design is unstable, this V&V becomes extremely difficult since the 
outputs will exceed the limits very fast. Also, typically there are multiple control modes for operation 
over a wide envelope. For aircraft, the control mode switches from ground control to flight control 
based on the WoW (Weight on Wheels) switch. Having an unstable controller in any of the modes 
makes it difficult to predict as to what is going to happen when the mode switching takes place. 

Since MVC synthesis techniques do not guarantee controller stability, it is essential to check the 
stability of the controller resulting from a particular design formulation. If the controller is stable you 
can proceed to next step, otherwise you have to use trial and error to see if the synthesis problem can 
be formulated in such a way as to result in a stable controller. This might mean changing the 
performance specifications, i.e., choosing different weighting functions, adding different sensors, 
choosing different outputs to control etc. If the plant is unstable and you set aggressive performance 
goals, then there’s a high likelihood that you might end up getting an unstable controller. 

An unstable plant is called “strongly stabilizable” if there exists a stable controller which will 
stabilize the plant in a closed-loop system. If the plant is not strongly stabilizable, then no MVC 
approach will give a stable controller. However, most physical systems are “strongly stabilizable” or 
can be made so by the right choice of sensors. If repeated trials end up in an unstable controller, then 
it is worthwhile to perform analysis to see if the plant is strongly stabilizable. 
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MVC Implementation Challenges: 
Controller Scheduling 


• Implementation requires “gain scheduling” controller for operation 
over wide envelope 

- Controller of order n with r inputs and m outputs requires 
n(1+m+r)+mr parameters scheduled 

- Closed-loop stability not guaranteed between design points 

• Simplified scheme that exploits 
robustness of control design 

• Match loop transfer function at 
controlled output 

• Determine Ks to: 
Min||G(s)KsK°(s) - 

G°(s)K°(s)|| 

• Only m 2 parameters to 
schedule 

Glenn Research Center 

MU' 



+ e u (i) z 

— H * K°{s) * G*(s) — X- 


(a) Nominal Control Loop 


K°(s) - K, 


(i) z 

G(s) 


(b) Off- Design Control Loop 


MVC Implementation Challenges: Controller Scheduling 

The traditional approach to designing feedback control laws for complex nonlinear systems is to 
design linear control laws at various operating points and then “gain schedule” the control laws 
through some kind of curve fitting of the various controller gains with the critical operating point 
variables as the independent scheduling parameters. One of the difficulties with implementing gain 
scheduling for MVC laws is the complexity of the scheduling. For a controller of order n with r 
inputs and m outputs, there will be n(l +m+r)+mr controller parameters to schedule. Furthermore, 
although the closed-loop system is stable for all design points, the stability of the closed-loop system 
is not guaranteed when operating between design points. 

The fundamental objective in using Robust MVC design techniques is to reduce the controller 
complexity while guaranteeing the desired performance and robustness characteristics. The above 
figure shows a simplified controller scheduling scheme which consists of scheduling only the output 
matrix of a nominal controller which is designed to give a robustly stable closed-loop system over a 
wide range of plant operating conditions. The scheduling scheme is of the form: K(s) = KsK°(s), 
where K(s) is the scheduled controller, Ks is the controller output scheduling matrix and K°(s) is the 
nominal controller. For such a scheduling scheme there are only m 2 parameters to schedule. The 
approach to synthesize the scheduling gains Ks consists of applying parameter optimization 
techniques such that the transfer function matrix with the loop broken at the controlled outputs {(i) in 
fig. b. above) “closely” matches the output loop transfer matrix of the nominal control loop. The 
details of the controller scheduling synthesis approach are described in the Reference listed below. 
This scheduling scheme is highly effective when the major change in the plant across the different 
operating points is in control effectiveness. An example application will be discussed next. 

Ref.: Garg, S., “A Simplified Scheme for Scheduling Multivariable Controllers,” IEEE Control 
Systems , August 1997, pp. 24-30. 
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MVC Implementation Challenges: 
Controller Scheduling (cont.) 


• Solved as constrained 
parameter optimization 
problem: 

- Control design at 
80 knots provided 
stability robustness for 
100-knot model 

- Primary change from 80- 
to 100-knot model was 
in control effectiveness 

- Simplified scheduling 
scheme provided close 
to “nominal” response at 
off-design point 
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MVC Implementation Challenges: Controller Scheduling (cont.) 

The STOVL IFPC design discussed earlier was implemented as separate, but interconnected, flight 
and propulsion controllers. The H-infinity based design was performed at the nominal flight 
condition corresponding to 80 knots air speed. The controller was designed for the transition flight 
regime, where the control of the aircraft is transitioning from aerodynamically generated forces to 
propulsive forces, which ranges from 50 to 120 knots. Since the nominal control design provided 
closed loop stable response throughout the transition flight regime, and also the most significant 
change in aircraft response to control inputs in this operating regime is that of control effectiveness, it 
was decided to apply the simplified controller scheme to extend the operation of the nominal control 
design to the transition flight regime. 

The results for the controller scheduling scheme application to the propulsion control are shown in 
the above figure. The solid line in the figure shows the response of the propulsion system to a step 
command in the Ventral nozzle thrust (FGV) for the nominal design point with the nominal 
controller. The dashed line shows this response for the propulsion model at 100 knots with the 
nominal controller. The need for scheduling the controller is evident from the degraded FGV 
command tracking response and the increased coupling with the engine rotor speed (N2). The dotted 
line shows the response when the controller is scheduled using the gains from the simplified 
scheduling scheme. The results indicate that the simplified scheduling provides a response which 
closely matches the response of the nominal system with the nominal controller in decoupled 
command tracking. 

Detailed results of the application of the simplified scheduling scheme to the STOVL propulsion 
system control design are described in the reference listed on page 12, and those for the IFPC design 
are described in the reference listed below. 

Ref.: Garg, S., and Mattem, D., “Application of an Integrated Methodology for Propulsion and 
Airframe Control Design to a STOVL Aircraft,” AIAA Paper no. 94-3611, Guidance, Navigation 
and Control Conference, Scottsdale, AZ, August 1994. 


NASA/TM — 2008-2 1 5027 


13 



MVC Implementation Challenges: 
Integrator Windup Protection 


• What is integrator windup? 

- Integrator action in controller drives steady-state errors to zero 

- If controller outputs are limited, such as actuator position limit, 
integral action will continue to command higher controller output — 
thus controller integrator(s) will wind up 

- Results in deteriorated performance since controller integrator 
must first “unwind” when high actuator deflections are not needed 

- Windup can even lead to system instability 

• IWP Design Requirements: 

- Should: be memory-less; provide smooth transfer; be closed-loop 
stable; provide graceful performance degradation 

• For SISO, IWP simply requires “stopping” integration when limit is 
encountered 


1 How to do this in MVC systems? 
Glenn Research Center 
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MVC Implementation Challenges: Integrator Windup Protection (IWP) 

In a control system, the effort to drive steady-state errors to zero is accounted for through integral 
action on part of the controller. If at any point in time the controller outputs are limited and controller 
inputs are non-zero and of the same numerical sign (+/-), the integral action of the controller will 
attempt to increase the magnitude of the already limited controller output, thus the controller’s 
integrator(s) will wind up. Following this period of integrator windup, the controller response to 
command inputs might be very poor because the controller’s integrators must first unwind prior to 
attempting to calculate the new controller outputs for the new controller inputs. Thus, Integrator 
Windup Protection (IWP) must be included in control systems designed for tracking commands with 
zero steady-state error. 

Integrator windup protection (IWP) design requirements are: i) Should be memory-less and not 
contribute to controller output when actuation system limits are not encountered; 2) Should provide 
smooth transfer between limited and unlimited case and provide accurate tracking of limited actuator; 
3) Should be closed-loop stable for all possible limit combinations; 4) Should attempt to maintain 
system performance and provide graceful degradation when limit is encountered. 

For single-input single-output systems, simply stopping the integration when a limit is encountered 
meets all the IWP requirements. It is not clear as to how to best implement IWP in multivariable 
control systems. Numerous ideas for integrator windup protection and bumpless transfer have been 
published in literature and will be discussed briefly next. 
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MVC Implementation Challenges: 
IWP (cont.) 


Controller states modified based on difference between 
commanded and limited actuator value 

Gains selected to provide stable effective controller, 

1 column at time for single limited actuator 

Typical IWP synthesis 
techniques require 
controller to be 
represented in specific 
form and do not 
guarantee closed-loop 
system stability 

- Very much trial and errc 


Errors 
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MVC Implementation Challenges: IWP (cont.) 

To implement IWP on MVC systems, the controller is represented in the form shown in the above 
figure. The block “Integrator Windup Protection Gains” is added to the controller to modify the 
controller states whenever an actuation limit is encountered. The inputs to this block are the errors 
between the outputs of the controller (the commands to the actuators) and the actual actuator 
positions with the limit in place. This implementation of the controller meets IWP design 
requirement 1, that the IWP be memoryless and not affect the system when the controller outputs are 
not being limited. 

The IWP design techniques for MVC systems that have been published in literature consist of 
selecting the IWP gains one column at a time considering a single actuator to be limited. The column 
of gains is selected to ensure that the modified controller remains stable and provides good tracking 
of the limited command so as to minimize integrator windup, thus meeting the IWP requirement 2 
listed earlier. However, this approach does not guarantee that the closed loop system will remain 
stable when the IWP becomes active. Neither does it provide a systematic way of ensuring that the 
closed-loop performance will degrade gracefully when the limits are encountered. Application of this 
approach to the STOVL IFPC design resulted mostly in severe degradation in performance when the 
actuator limits were encountered, and in some instances this approach even resulted in the closed- 
loop system being unstable with the modified controller. 

A parameter optimization based scheme was developed to determine the IWP column gains such that 
for a single actuator saturation, the modified controller and the closed-loop system will remain stable 
while minimizing the loss in tracking performance compared to the “unlimited” system performance. 
This approach, which is described in detail in reference listed below, will be discussed next. 

Ref.: Watts, S.R., and Garg, S., “An Optimized Integrator Windup Protection Technique Applied to 
a Turbofan Engine Control,” AIAA Paper No. 96-3814, Guidance, Navigation and Control 
Conference, San Diego, CA, July 1996. 
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MVC Implementation Challenges: 
IWP (cont.) 


Gains determined to 
trade-off actuator 
and system tracking 
errors using 
parameter 
optimization 
approach 
Limits gains to 
ensure controller and 
closed-loop system 
stability 
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MVC Implementation Challenges: IWP (cont.) 

The generalized design plant for determining the parameter optimization based IWP gains is shown 
in the figure above. This problem set up allows for the calculation of errors between the nominal 
closed-loop, or “ideal” system, and the limited system with IWP for the performance loops and the 
actuator command tracking error. The performance errors, ZERROR, are defined as the difference 
between the response of controlled variables for the nominal system, ZNOM, and the response of the 
controlled variables for the limited system with IWP, ZLIMITED. The controlled actuator error, 
UERROR, is defined as the difference between the commanded actuator position, UC, and the 
controller with IWP commanded actuator position, U. For a single actuator being limited, the 
corresponding column of the IWP gains is obtained by minimizing the weighted sum of squares of 
ZERROR and U . The relative weighting between these two errors can be used as a “design handle” 
to trade-off between providing tight IWP versus providing tighter tracking performance. The closed- 
loop stability and controller stability is guaranteed with the selected IWP gains by checking for both 
during the optimization process and setting the cost being minimized to be high if any of these 
conditions is violated. 

The second figure above, from reference listed below, shows an example result from application of 
the optimized IWP technique to the propulsion control portion of the STOVL IFPC design. Shown 
are the response of the aft nozzle thrust (FG9) to a step command and the corresponding fuel flow 
(WF36) requirement with and without the IWP. Without IWP, dashed lines, when the fuel flow limit 
is encountered, the fuel flow command continues to grow because of integrator wind up. As the FG9 
command is taken out, the integrator takes time to wind down and the FG9 response is degraded. 
With IWP active, solid lines, the fuel flow command tracks the fuel flow limit and good FG9 
tracking performance is obtained when the step command is removed. 

Ref.: Mattem, D., and Garg, S., “Propulsion System Performance Resulting from an Integrated 
Flight/Propulsion Control Design,” AIAA Paper No. 1992-4602, Guidance, Navigation and Control 
Conference, Hilton Head, SC, August 1992. 
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Iterative Process for Control Design 

Simplistic look at control design and implementation process: 



• Classical/SISO approaches provide “knobs” that can be tuned 
during “hardware” testing process to meet specs 

- Easier to make minor mods for small changes in plant 

• Not clear how to do this with MVC 

- Typically need to go back to control logic design or earlier stSps 

Glenn Research Center 



Iterative Process for Control Design 

The figure above provides a very simplistic look at the control design process. Given performance 
specifications and a math model of the system, the control design problem is formulated in such a 
way as to provide the desired trade-off between performance, robustness and control usage. Once an 
acceptable control law is obtained through the control synthesis process, it is implemented in the 
nonlinear simulation and tested to ensure that controller scheduling and limit protection are 
appropriately implemented. Once the nonlinear evaluation provides satisfactory results, then the 
control laws are converted to software to be implemented in the control hardware. Extensive 
software V&V (Verification and Validation) is conducted to ensure that the software is error free and 
faithfully implements the control law as designed. The control software is then implemented on 
hardware and hardware-in-loop testing and testing on the actual system (flight test for example) is 
conducted. 

This is where the so-called “rubber hits the road”. Till now all the control development and 
evaluation had been based on some mathematical models, and mathematical formulations of 
uncertainties etc. Once the control is implemented on the real system and tested under realistic 
operating conditions, that is the final test of whether the control design meets the system performance 
objectives or not. Rarely does it happen that the control design as first implemented meets all the 
objectives over the wide operating envelope. Typically there will be shortcomings identified in the 
testing and these will have to be fixed in order to certify the control design as fully operational. 

For single-input single-output systems with classical control structure, such as PID 
(Proportional+Integral+Derivative), the control gains provide individual “tuners” to be adjusted 
during testing to make modifications as needed. How to do such modifications on the fly for MVC 
systems is not at all clear. One almost has to go back to the step one of reformulating and 
resynthesizing the original control law in order to address the shortcoming. This is one of the 
fundamental reasons why MVC has not found application in operating aerospace systems. 
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Modifying MVC Designs 


Understanding physics of problem useful to make mods without 
having to resort to major control redesign 
STOVL example: 

- Initial piloted evaluation showed high-frequency pitch oscillation 

- Cause of oscillation isolated to time-delays because of digital 
implementation; duplicated by including time delay in simulation 

- Pitch damping improved by 


adding pitch rate error 
feedback to elevator 
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Modifying MVC Designs 

All is not lost though when it comes to having to make modifications to the MVC design in the final 
stages of testing. Understanding the physics of the problem comes in useful in making the 
modifications without having to go back to step 1 of reformulating the control design problem and 
starting all over with the controller synthesis. 

For the STOVL IFPC design, initial piloted evaluations in a fixed-base simulator uncovered some 
problems which had not been apparent in the non-realtime evaluation of the design. One of the 
problems was a pitch oscillation during deceleration from cruise to hover. The figure above shows 
the pitch attitude response of the aircraft, from the simulator, for a simultaneous command of flight 
path change and deceleration. The solid line in the figure above is for the nominal IFPC design and 
shows the pitch oscillation. Analysis indicated that this oscillation is due to the significant time delay 
between the computer that hosts the aircraft simulation and the computer that implements the IFPC 
design. The IFPC design was such that it resulted in a low damped aircraft short period mode, and 
the phase loss due to time delay in the real-time simulation environment resulted in the observed 
oscillatory behavior. 

To improve the damping of the pitch mode, the IFPC design was modified to include an additional 
constant gain feedback loop from the pitch rate error to the elevator as shown in the block diagram 
above. The root locus technique was used to determine the value of the feedback gain to provide 
improved short period mode damping without having any significant effect on the other closed-loop 
poles. The dashed line in the above figure shows that with this modification, the IFPC design 
resulted in well damped pitch response. The reference listed below provides additional details of how 
such knowledge of the physics led to successful implementation of the IFPC design. 

Ref: Bright, M.M., et al. “Piloted Evaluation of an Integrated Methodology for Propulsion and 
Airframe Control Design,” AIAA Paper No. 94-3612, Guidance, Navigation and Control 
Conference, Scottsdale, AZ, August 1994. 
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• Potential benefit of multivariable control design: 

“Improved performance and robustness to modeling uncertainties 
achievable with highly complex systems” 

• Use MVC design with Caution: 

- Make sure MVC is really needed 

- Get good understanding of physics of problem 

• You cannot make 747s fly like F-16s, no matter how good a 
control engineer you are! 

- Make sure that synthesis problem is formulated right 

• Control effector blending 

• Nonlinearities around small perturbation model 

• Controller stability and order 

- Give thought to scheduling and IWP issues before deciding on 
control structure 

• Keep these as simple as possible 

- Use knowledge of system to make “smart” amendments based 
on test results 

Glenn Research Center 
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Conclusion 

Potential benefit of multivariable control is the improved performance and robustness to modeling 
uncertainties, achievable with highly complex systems. So if you are working with a highly complex 
system and very tight performance requirements, then maybe multivariable control is the way to go. 
However, multivariable control should be used with caution and analysis should be done to ensure 
that the use of MVC is justified. 

As discussed throughout the paper, getting a good understanding of the physics of the problem is 
essential for the MVC design to be successful in realistic application. Remember that the control 
synthesis process is just a convenient mathematical formulation which results in a tractable, solvable 
control law. The formulation has to take into account the inherent limitations of achievable 
performance for the “plant”. You cannot make a 747 fly like an F-16, no matter how good a control 
engineer you are. Formulating the synthesis problem right means you pay adequate attention to 
issues such as control effector blending, available control authority and effect of nonlinearities 
around the small perturbation model. Once the synthesis process results in a controller that meets the 
closed-loop performance specifications, at least for the design plant, then from an implementation 
perspective, it is important to ensure that the controller itself is stable and that its order can be 
reduced to a “reasonable” number of states. Before starting with the controller synthesis process, 
thought should be given to the overall controller structure in terms of gain scheduling and integrator 
wind up protection. As has been discussed in the paper, the robustness characteristics of the 
controller design can be used to simplify the controller scheduling. 

Finally, use knowledge of the system to make smart amendments based on test results. Keep in mind 
that the controller will be implemented in discrete form and computational effort and sampling will 
result in effective time delays which should be accounted for in the design. Some of the 
shortcomings of the MVC design can be overcome in the implementation stage by applying classical 
control methods in conjunction with a good understanding of the plant dynamics. 
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